1. Field of the Invention
This invention relates to multitasking computer programming techniques, specifically, to "pipeline" programming. Pipeline programming environments are well known in the art. A pipeline is a series of several independent programs called "stages." The output data from one stage flows into the input of the next stage. A pipeline is like an assembly line in which the work pieces are data, and at each stage, some operation is performed on the data.
2. Prior Art
Pipelines are usually used in multitasking environments. Using pipelines in such an environment saves time and computing resources. In most operating environments where pipelines are available, a pipeline is created within a task and put into operation with a single command in which the various stages to be combined in series are specified as parameters of that command. For example, in the CMS operating system, a pipeline is created with the "pipe" command, and the stages are specified as parameters separated by vertical bars. A simple CMS pipe command might be: EQU pipe&lt;text file count words console
The command "pipe" invokes a pipeline supervisor, a program that manages the flow of data through the various stages of the pipeline. The first stage is specified by &lt; and reads the contents of a file called "text file". The second stage is specified by the parameter "count words" and counts the words in that file, and the third and last stage is called "console" and displays the output from the preceding stage (the word count) on the computer console. Complete details on how to use CMS pipelines can be found in the publication, Virtual Machine/Enterprise Systems Architecture CMS Pipelines User's Guide, Release 1.1, IBM Publication Number SC24-5609-00, 1992, which is incorporated herein by reference.
Problems can arise with pipelines when one stage in a pipeline sends a service request to a program, system, or device outside of the pipeline, and the response to the service request is to be received by a subsequent stage in the pipeline. The service request could be directed simply to another program running in the same processor and memory but outside the address space of the task running the current pipe command. Or, the service request could be directed to another computer system or to a peripheral such as a printer or a disk drive. In any case, the service supplier will send back responses asynchronously, that is independently of what the pipeline is still doing or whether the pipeline even still exists.
FIG. 1A shows a conceptual block diagram of the stages involved in the above service request process. The names chosen for the various stages are generic. The "pipeline supervisor" 12 controls the overall flow of information in the pipeline. The stage generating the request is called the "request generator" 1. It sends the request to the next stage, the "request transmitter" 2, which is a program to access whatever transmission path is needed to send the request to the appropriate place. A subsequent stage in the pipeline is called the "response waiter" 3 because it waits for a response to the service request, and then passes it on to the appropriate subsequent stage, the "destination" 4.
The response waiter pipeline stage receives all general responses arriving at the task on which the pipeline is running. Since many pipelines are being invoked, run, and terminated constantly on a given task, there is a constant flow of responses arriving from various service suppliers. The response waiter must understand all of the possible responses for a given service request. Some responses will have been delayed and will be to service requests from pipelines that no longer exist. In addition, unsolicited responses that are not related to the current pipeline's service request arrive constantly at the task. To account for these problems, the user must add stages to an individual pipeline to filter out unwanted, duplicative or late responses. It may not be possible to distinguish a late response from the desired response. In either case, extra time and processing power is used by the response waiter and any necessary filtering stages in analyzing and possibly discarding responses.
What is needed is a method to uniquely tag each service request in a way so that a response to a service request will be sent back to the pipeline bearing the tag. Additionally, a timing mechanism needs to be provided so that responses which are delayed so long that they can no longer be used can be identified and discarded. Such a response is called a "stale" response.